home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0067.001 < prev    next >
Text File  |  1992-08-02  |  6KB  |  137 lines
  1. Document: FSC-0067
  2. Version:  001
  3. Date:     02-Aug-1992
  4.  
  5.  
  6.  
  7.  
  8.                  A Proposal For Sensible New Kludge Lines
  9.                  ========================================
  10.                                
  11.                               Mark Kimes
  12.                            FidoNet 1:380/16
  13.  
  14.  
  15.  
  16.  
  17. Status of this document:
  18.  
  19.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  20.      and requests discussion and suggestions for improvements.
  21.      Distribution of this document is unlimited.
  22.  
  23.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  24.      Software.
  25.  
  26.  
  27.  
  28.  
  29. MSGTO:  This kludge line, together with a MSGID: kludge (see FTS-0009),
  30.         would provide full address specs for both the originating and
  31.         destination nodes of a netmail message (MSGTO should _not_ be
  32.         used in echo mail).  Its format is simple:
  33.           ^aMSGTO: <FTN address>
  34.         MSGTO (coupled with MSGID) would eliminate the need for the
  35.         INTL, FMPT, TOPT and DOMAIN kludges.  A MSGTO kludge line should
  36.         go just below any MSGID and REPLY kludge lines.  See also
  37.         discussion on FTN address representation below.
  38.  
  39. ASSOC:  ASSOC introduces a filename that should follow the message (is
  40.         associated with the message). Format is, again, simple:
  41.           ^aASSOC: <filename>
  42.         A message tosser would forward the file along with the message,
  43.         if so configured for the AREA: of the message (assuming
  44.         echomail) or other criteria.  Paths would probably not be useful
  45.         in the <filename> field and should not normally be included or
  46.         used if found to be present.  ASSOC kludge lines should go below
  47.         any addressing kludge lines.
  48.  
  49. SPTH:   Clint Adams described this as a "5D, sensible order,
  50.         top-of-the-message path" line.  I like that.  Stands for "Sticky
  51.         PaTH."  SPTH displaces the current PATH line.  Instead of being
  52.         located at the bottom of the message, it's located at the top of
  53.         the message.  Instead of being 2-D (net/node), it's 5-D
  54.         (domain#zone:net/node.point).  It's sticky like a normal PATH
  55.         line so that the size doesn't get outrageous.  Because it's 5-D
  56.         instead of 2-D it can be used for dupe checking (which a normal
  57.         2-D PATH line cannot; is 1/1 Fidonet#1:1/1 or Dufusnet#2:1/1?).
  58.         Because it's 5-D we would no longer have to go through hideous
  59.         gyrations when gating echo mail from one domain to another; just
  60.         let it flow.  Using SPTH it becomes trivial to cut SEEN-BYs down
  61.         to Tiny Seenbys (only required for backward compatibility with
  62.         old mail processors that barf without some SEEN-BYs, and to
  63.         protect fully enclosed polygon topology).
  64.  
  65.         SPTH is to be used only in echo mail.  It's format is basically:
  66.  
  67.             ^aSPTH: <address> <address> ... <address>
  68.  
  69.         SPTH lines, like PATH lines, contain only addresses of mail
  70.         processors that actually processed the message.  SPTH lines are
  71.         specifically not sorted and are "sticky" so that they carry the
  72.         least amount of information that will convey a full address when
  73.         coupled with preceding addresses.  For example, if
  74.         1:380/16.0@Fidonet, 1:380/16.1@Fidonet, 1:380/100.0@Fidonet,
  75.         1:396/100.0@Fidonet, 2:4177/1.0@Fidonet and 2:4177/1.0@Othernet
  76.         processed a message, in that order, you'd have:
  77.  
  78.          ^aSPTH: Fidonet#1:380/16 .1 100 :396 #2:4177/1 Othernet
  79.  
  80.         Note that point 0 is assumed if missing and that punctuation
  81.         *precedes* an address element except in the case of a domain
  82.         change (and when the net element is the first change -- this
  83.         dictates that domain names begin with an alphabetical
  84.         character).  This compacts SPTH entries as much as possible for
  85.         most typical topologies.
  86.  
  87.         When an SPTH-aware processor forwards a message containing (a)
  88.         PATH line(s) but no SPTH line(s), it should create a new SPTH
  89.         line (or lines as required; SPTH lines shouldn't get longer than
  90.         80 characters, including terminating carriage return) containing
  91.         "fleshed-out" addresses from the PATH line(s), then add itself.
  92.         If this is done at all zone/domain gates, the SPTH will always
  93.         be current even if intermediate nodes are not SPTH-aware.  In
  94.         the event an SPTH-aware processor receives a message containing
  95.         both SPTH line(s) and PATH line(s), it should concatenate the
  96.         "fleshed-out" addresses from the PATH line(s) to the SPTH
  97.         line(s), then add itself.  The PATH line(s) may then be
  98.         discarded from the message.  When exporting new messages, only a
  99.         SPTH line should be created; no PATH line should be generated.
  100.         Tiny Seenbys should be added at the end of the message for the
  101.         reasons noted above.
  102.  
  103.  
  104. Note that all the kludge lines above are in actual use and have been for
  105. some time; they do work, and work as presented.  Code is available on
  106. request, but implementation is trivial (only SPTH takes any real work at
  107. all).
  108.  
  109.  
  110.  
  111. FTN address representation:
  112. ==========================
  113.  
  114. The current convention for representing an FTN address has become:
  115.  
  116.     zone:net/node[.point]@domain
  117.  
  118. I propose we change this to:
  119.  
  120.     domain#zone:net/node[.point]
  121.  
  122. Why?  It's all in one order, highest to lowest; it's consistent.  "@" is
  123. used, in the former method, in a way rather opposed to normal usage in
  124. network addressing.
  125.  
  126. While we're on the subject of domains, let's knock off using
  127. "fidonet.org" in FTN addresses.  That only means something in Internet.
  128. It's going to gum up the works for FTN domains, where we'll want things
  129. like "fidonet.eu" to mean Fidonet Europe some day.
  130.  
  131. I'm done now.
  132.  
  133.  
  134. Mark Kimes
  135. Fidonet#1:380/16
  136. (318)222-3455 data
  137.